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ABSTRACT 


In  this  thesis,  we  discuss  the  development  of  the  neces- 
sary tools  for  the  performance  evaluation  of  a  multi-backend 
database  system,  known  as  MDBS.  The  basic  motivation  of  the 
mutlti-backend  database  system  (MDBS)  is  to  develop  an 
architecture  which  spreads  the  work  of  the  database  system 
among  multiple  backends.  It  is  a  major  aim  of  this  system 
to  allow  capacity  growth  by  the  use  of  additional  disk 
drives  and  performance  improvement  by  the  usa  of  additional 
backends.  However,  to  verify  the  design  and  implementation , 
it  is  necessary  to  test  the  capability  of  MDBS  in  capacity 
growth   and  performance  gain. 

Three  tools  for  the  performance  and  capacity  tests  are 
investigated.  The  first  tool  is  the  file  generation  package 
which  creates  test  files  for  any  artificial  database.  The 
second  tool  is  the  database  lead  subsystem  which  loads  the 
artificial     database    into      MDBS.  The      third    tool      is     the 

reguest  generation  package.  This  package  creates  test 
reguests   to  guery   MDBS. 

The  following  methodology  is  used  to  create  an  effective 
tool.  First,  the  properties  of  an  ideal  tool  are  described. 
Then  available  existing  programs  are  reviewed  and  evaluated 
to  determine  which  program  best  meets  the  desired  features. 
Lastly,  the  programs  are  upgraded  to  ensure  that  they  are 
compatible  with  the  current  implementation,  and  meet  the 
desired    features. 

The  main  goal  is  to  develop  the  necessary  tools  to 
generate  tests  in  measuring  the  extensibility  of  MDBS,  i.e., 
how  does  MDBS  perform  as  mors  backends  are  added? 
Performance  is  expected  to  improve  (maintain)  as  the  number 
(size)     of    the    backends    (database)    is    increased. 
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I*    AH   INTRODUCTION 

This  chapter  presents  a  brief  review  of  the  multi- 
backend      database      system      (MDBS).  First,        the      physical 

arrangement  of     MDBS   is  presented.  This   is   followed     by    a 

presentation  of  the  process  structure  of  MDBS.  Lastly,  the 
actions  taken  in  servicing  requests,  both  insert  and  non- 
insert  requests,  are  reviewed.  References  are  cited  for  the 
interested  reader  in  order  to  gain  a  more  detailed  under- 
standing  cf  MDBS. 

A.      THE    HULTI-BACKEBD    DATABASE    SYSTEM 

The  multi- tackend  database  system  (MDBS)  uses  one  mini- 
computer as  the  master  or  controller,  and  a  varying  number 
of  minicomputers  and  their  disks  as  slaves  or  backends. 
MDBS  is  designed  to  provide  database  growth  and  performance 
enhancement      by   the     addition      cf     identical  backends.  No 

special    hardware   is  required.  The    backends   are   configured 

in  a  parallel  fashion.  A  new  tackend  may  be  added  by  simply 
replicating  the  existing  software  on  the  new  backend,  thus 
avoiding  reprogramming  efforts.  A  prototype  MDBS  has  been 
completed  in  order  to  carry  out  the  design  verification  and 
performance  evaluation  developed  in  [Ref.  1]  and  [Bef.  2]. 
The  implementation  efforts  are  described  in  [Ref.  3]  through 
CRef.    5]. 

The  equipment  configuration  of  the  system  is  shown  in 
Figure  1.1.  The  host  computer  is  connected  to  MDBS  through 
the     controller.  The      backends     are     connected        to     the 

controller  through  a  broadcast  bus.  When  the  controller 
receives  a  request  frcm  the  host,  it  delivers  the  request 
to     all      backends      simultaneously   over     the      broadcast      bus. 
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Since  the  data  is  distributed  across  all  backends,  all  bick- 
ends  can   execute   a   request  in    parallel. 

The  division  cf  labor  between  the  controller  and  the 
backends  is  illustrated  through  the  process  structure  of 
Figure  1.2.  The  MDBS  controller  handles  three  functions. 
The  re  quest  preparation  function  prepares  a  request  for 
transmission  to  the  backends.  The  insert  information  gener- 
ation function  processes  the  insert  requests  which  require 
additional  information  used  by  the  backends.  The  oost 
processing  function  handles  the  work  necessary  when  the 
replies  are  returned  to  the  controller  from  the  backends  but 
before   reaching   the    host. 

The  backends  in  MDBS  carry  out  three  different  func- 
tions. The  directory  management  function  performs 
descriptor  search,  cluster  search,  address  generation,  and 
directory  table  maintenance.  The  record  £rocessiiK[  function 
performs  record  storage,  record  retrieval,  rscord  selection, 
and  attribute-value  extraction  of  the  retrieved  records. 
The  concurrency  control  function  performs  operations  to 
ensure  that  the  concurrent  and  interleaved  execution  of  the 
user  requests    will   keep  the   database    consistent. 

Before  proceeding  to  describe  the  sequence  of  actions 
required  during  a  reguest  servicing,  some  terminology  is 
presented   as      a   review.  The   smallest      unit   of      data   is      a 

keyword,  which  is  an  at  tribute- value  pair.  Information  is 
stored  in  terms  of  records,  which  are  made  up  of  keywords 
and  a  record  body.  A  predicate  is  of  the  form  (attribute, 
relational  operator,  value).  A  query  is  any  Boolean  expres- 
sion of  predicates.  Records  are  logically  grouped  into 
clusters  based  on  the  attribute  values  and  the  attribute- 
value  ranges  in  the  records.  Internally,  the  values  and 
value  ranges  are  called  descriptors.  For  the  user,  these 
attribute  values  are  termed  keywords.  Each  descriptor  is 
identified  by      a   descriptor      id  to      save   computing      time  and 
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memory  space.  A  prespecif ied  set  of  requests  is  referred  to 
as   a  transaction. 

B.       REQUEST    EXECOTIOH 

This  section  describes  the  sequence  of  actions  taken  by 
MDBS  in  carrying  out  a  request.  First,  the  insert  request 
will  be  discussed.  Then  the  non-insert  requests  will  be 
described.  Non-insert  requests  are  requests  for  deletion, 
retrieval,  or   update. 

1-      Actions   for   Insert  Requests 

The  sequence  of  actions  for  an  insert  request  is 
shown  in  Figure  1.3.  A  request  from  the  host  machine  enters 
the  Request  Preparation  process.  Request  Praparation  broad- 
casts the  number  of  requests  in  the  transaction  to  Post 
processing  in  order  to  determine  when  a  transaction  is 
completed.  Request  Preparation  may  send  an  error  to  Post 
Processing  if  there  is  a  syntax  error  in  the  request.  When 
a  transaction  is  completed  Post  Processing  sends  the  results 
to  the  host  machine.  Request  Preparation  then  broadcasts 
the  request  to  Directory  Management.  Each  backend  finds  the 
descriptor  ids      associated   with  the  request.  The    backends 

then  exchange   descriptor    id  information. 

After  receiving  the  descriptor  ids  from  the  other 
backends.  Directory  Management  sends  the  cluster  id  to 
Insert        Information       Generation.  Insert        Information 

Generation  then  determines  which  backend  is  to  store  the 
record.  The  selected  backend  determines  the  address  of  the 
new  record  and  stores  it.  The  other  backends  discard  the 
record.  Finally,  Record  Processing  sends  an  action- 
completed  message  to  Post  Processing,  which  in  turn  informs 
the  host. 
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Figure     1.3  SEQUENCE    OF    ACTIONS    FO F    AN    INSERT    REQUEST. 
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2-      Actions    for   Ncn- insert   Bequests 

The  sequence  of  actions  for  a  non-insert  request  is 
shewn  in  Fiqure  1-4.  The  actions  for  a  retrieve  will  be 
discussed  only,  since  the  other  types  of  requests  are  quite 
similar.  A  request  from  the  host  machine  enters  the  Request 
Preparation  process.  Request  Preparation  sends  the  number 
of  requests  in  the  transaction  to  Post  Processinq  in  order 
to     determine   when     a     transaction     is  completed.  Request 

Preparation  may  send  an  error  to  Post  Processinq  if  there  is 
a      syntax   error      in     the   request.  When     a   transaction     is 

completed,  Post  Processinq  sends  the  results  to  the  host 
machine.  Request  Preparation  then  broadcasts  the  request  to 
Directory  manaqement.  Each  backend  finds  the  descriptor  ids 
associated  with     the    request.  The    backends      then   exchange 

descriptor  id    information. 

After  receiving  the  descriptor  ids  from  the  other 
backends,  Directory  Manaqement  determines  the  cluster  ids. 
Lastly,  Directory  Manaqement  determines  the  addresses  of  the 
records  of  the  identified  clusters.  Record  Processing  gets 
the  records  from  secondary  storage  and  extracts  the  neces- 
sary information.  If  aqgregate  operators,  for  example,  the 
average,  are  specified  in  the  retrieve  request,  they  are 
applied  at  this  time.  The  partially  aggreqated  values  are 
sent  to  Pest  Processing.  Post  Processinq  sends  the  results- 
to   the   host  following   any    further   aggregate  operations. 

This  concludes  the  review  of  MDBS.  Attention  is  now 
turned  toward  performance  issues  of  this  system  in  the 
following   chapter.  


16 


Controller 


Post 
Process tng 


T 


Reauest 
Preparation 


Insert 
Inf ormatton 
Generation 


G_PCl 


P.PCL 


*-■ 


! p_pcl 


Backend 


T 
i 
i 


g.pcl| 


1  Directory 
(Management 


Record 
Processing 


Concurrency 
Control 


i 


Figure     1.4         SEQUENCE   OF    ACTIONS    FOR     A    NON-INSEHT    REQUEST. 
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II.  PERFORMANCE  E?AL0ATIOH 

A.  TWO  YIEWS  OF  PERFORMANCE  MEASUREMENT 

Now  that  the  MEBS  has  been  described,  it  is  reasonable 
to  ask  "how  does  one  determine  the  performance  of  such  a 
system?"  There  are  two  viewpoints  of  performance  evalua- 
tion. The  first  is  the  macroscopic  viewpoint  in  which  the 
key  performance  measurement  is  the  relative  response  time. 
The  second  viewpoint  is  the  microscopic  viewpoint.  This 
viewpoint  is  concerned  with  measuring  the  times  needed  to 
perform  various  subtasks  which  are  carried  out  in  servicing 
a  request.  In  [Ref.  6],  the  motivation  for  the  macroscopic- 
measurement  is  provided.  This  chapter  is  concerned  with 
describing  the  perfcrmance  issues  which  arise  when  using  the 
macroscopic  viewpoint.  Thus  in  testing  the  MDBS,  the  macro- 
scopic viewpoint  will  be  used  before  proceeding  to  the 
microscopic  viewpoint. 

B.  CRITERIA  FOR  PERFORMANCE  EVALUATION  AND  TOOL  SELECTION 

1 •      H§££2scc£ic  Viewpoint 

As  stated  above,  with  the  macroscopic  viewpoint  the 
key  performance  measurement  is  the  relative  response  time. 
That  is,  the  concern  lies  mainly  with  the  affect  of  various 
changes  to  the  system  en  the  response  time.  These  changes 
and  therefore  their  relative  response  times  are  prompted  by 
the  variables   described  in  the   following   section. 
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2-      Performance   Issues 

The  macroscopic  viewpoint  is  concerned  with  changing 
four  categories  of  variables  and  observing  their  affect  on 
the  relative  response  time.  These  variables  include  system 
configuration      variables,  cluster      formation        variables, 

request    construction   variables,  and   storage   variables. 

The  system  configuration  variables  deal  with  the 
following  guesticns  on  how  MDBS  performs  when:  the  number 
of  backends  remains  constant  but  the  database  increases,  the 
database  remains  constant  and  the  number  of  backends 
increases,  the  number  of  concurrent  users  increases,  the 
number  of  requests  per  transaction  increases,  and  the  pres- 
ence of  concurrency  ccntrol  is  measured  against  the  absence 
of  concurrency   control. 

The  cluster  formation  variables  deal  with  the 
following  guestions  on  how  MDBS  performs  when:  the  number 
of  descriptors  on  any  attribute  increases,  the  average  size 
of  clusters  in  the  database  ranges  over  small,  medium,  and 
large  size,  and  the  number  of  attributes  and  thus  the  size 
of   the   attribute   table  increases. 

The  request  constructicn  variables  deal  with  the 
following  guesticns  on  how  MDBS  performs  when:  the  request 
makeup  is  retrieve- intensive  vs.  update-intensive,  the 
complexity  of  the  query  increases,  the  relative  mix  of  query 
types  is  varied,  the  retrieved  information  is  either  a 
projection  of  the  record  or  the  whole  record,  the  query 
predicates  are  permuted,  and  the  request  uses  either  non- 
directory   keywords  or   directory  keywords. 

Lastly,  the  storage  variables  dsal  with  the 
following    questions      on  how  MDES      performs    when:  the   data 

placement  strategy  of  the  database  changes,  the  tuple  width 
increases,  and  the  size  of  the  retrieved  information  exceeds 
that   available    in   the   main  memory. 
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Thus  it  can  b€  seen  that  several  variables  influence 
the  performance  of  MDES.  This  is  not  an  all-inclusive  list. 
However,  the  list  will  serve  as  a  basis  for  developing  the 
desired  properties  of  each  performance  tool.  Each  tool  will 
be  discussed  along  with  its  desired  properties  in  the 
following   sections. 

C.  DESIRABLE    PROPERTIES    OF  THE  TEST    FILE   GENERATION    PACKAGE 

The  purpose  of  the  file  generation  package  is  to  create 
an  artificial  database  which  will  eventually  be  loaded  into 
MDES.  This  is  the  first  tool  tc  be  used  for  the  evaluation. 
Several  parameters  are  likely  to  be  varied  in  the  light  of 
the  performance  issues.  Their  desired  properties  are  as 
follows.  The      input     parameters   to      such      a      package      may 

include:  file     size     in     number        cf      records      per      file, 

attribute-value  size  in  bytes  of  storage,  record  size  in 
number  of  attributes  values,  data  types  of  attribute  values, 
and  database  size  in  number  of  files  per  database.  In  addi- 
tion, parameters  must  indicate  whether  values  of  attributes 
are  taken  from  randcm  functions,  or  from  predetermined  sets, 
and  whether   uniqueness  of    values  is  desired. 

D.  DESIRABLE    PROPERTIES    OF  THE   DATABASE   LOAD   SUBSYSTEM 

The  database  load  subsystem  is  responsible  for  taking 
the  files  created  by  the  file  generation  package  and  for 
properly  loading  the  files  into  MDBS.  In  the  process  of 
loading  the  database,  the  database  lead  subsystem  must  also 
create   the  necessary  tables   used  in   directory    management. 

The  database  lead  subsystem  must  be  designed  so  that  the 
performance  evaluation  may  utilize  various  cluster  formation 
variables  and  storage  variables  with  minimum  effort.  The 
cluster  formation  variables  and  storage  variables  with  which 
the  performance   may  be  concerned  include  the  following.      The 
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performance  may  be  expected  to  depend  upon  whether  the 
number  of  descriptors  (attributes)  is  large  or  small. 
Certainly,        when   entering     a      large      number  of      descriptors 

(attributes) ,  the  chance  for  error  in  this  menial  task  is 
great.         Therefore,      the    ease      of  specifying  the   descriptors 

(attributes)  must  be  guaranteed.  The  variation  of  cluster 
size  may  affect  performance.  The  cluster  size  is  a  function 
of  the  number  of  descriptors,  the  size  of  the  input  files, 
and  the  values  used  in  the  attribute  fields.  Therefore, 
these  three  parameters  should  be  entered  independently.  The 
data  placement  strategy,  i.e.,  how  records  are  distributed 
across  the  backends,  also  affects  performance.  While  simu- 
lation studies  described  in  [Ref.  1]  and  [Ref.  2]  show  that 
the  track-splitting-with-random-placement  strategy  is  the 
most  desirable,  the  ability  to  change  the  placement  strategy 
will  provide    a    means   cf  confirming   these    studies. 

E.      DESIRABLE    PBOPIRTIES    OF  THE   REQUEST    GENERATION   PACKAGE 

The  request  generation  package  is  concerned  with 
creating  and  executing  test  reguests.  The  request  formation 
variables  will  be  altered  by  the  performance  evaluation  team 
in  this  performance  evaluation  tool.  The  request  formation 
variables  will  te  changed  in  order  to  vary  ths  following: 
the  percentage  of  the  types  of  requests  (retrieve,  update, 
insert,  or  delete) ,  the  percentage  of  aggregate  operators 
(ave,  max,  min,  sum,  and  count)  in  retrieve  requests,  the 
complexity  of  the  request  query  (A  simple  query  will  consist 
of  one  to  two  predicates,  and  a  complex  query  will  consist 
of  ten  to  fifteen  predicates)  ,  the  order  of  the  predicates 
appearing  in  the  request,  and  the  number  of  attributes  to  be 
projected   in   the   retrieve    request. 
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The  request  generation  package  must  also  possess  the 
ability  to  allow  the  following:  vary  the  length  of  the 
transaction  to  determine  its  effect  on  system  performance, 
tag  requests  with  user  identification  in  order  to  test 
concurrency  control,  retrieval  of  a  record  defined  over  the 
null  descriptor,  execute  a  retrieve  reguest  where  the  entire 
cluster  is  stored  at  one  backend,  and  compare  the  above 
performance  with  a  retrieve  request  where  the  cluster  is 
distributed  across   all  backends. 

It  is  now  appropriate  to  proceed  to  the  details  of  each 
of  the  above  three  tools.  In  the  following  chapter  the  test 
file  generation  package  is  discussed.  Chaptar  IV  deals  with 
the  details  of  the  database  load  subsystem,  and  Chapter  V 
develops    the   test   request    generation    package. 
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III.    THE   TEST    PILE    GENERATION    PACKAGE 

In  this  chapter,  we  discuss  the  test  file  generation 
package  development.  In  the  first  two  sections,  we  review 
the  purpose  and  desired  properties  of  the  package.  In  the 
next  two  sections,  we  discuss  how  the  basic  program  was 
selected  from  existing  file  generation  tools.  Finally,  in 
the  last  two  sections  we  discuss  the  upgrading  of  the 
selected  program  and  future  enhancements  which  will  further 
aid  the    performance  evaluation   team. 

A.  THE    PDBPOSE 

The  first  set  cf  performance  evaluation  experiments  will 
use  test  data  which  is  generated  by  a  program  in  the  form  as 
specified  by  the  experimenter.  This  process  may  be  viewed 
in  three  steps.  The  first  step  consists  of  defining  the 
structure  cf  the  files  to  be  generated.  The  second  step 
determines  where  the  values  for  the  specified  attributes 
will  be  generated.  Lastly,  the  files  are  generated  and 
stored    for  future   use. 

B.  DESIRED   PROPERTIES 

The  input  parameters  to  such  a  package  may  include: 
file  size  in  number  of  records  per  file,  attribute  size  in 
bytes  of  storage,  record  size  in  number  of  attribute  values, 
data  types  of  attributes,  database  size  in  number  of  files 
per  database,  whether  values  of  attributes  are  taken  from 
random  functions  or  are  selected  from  predetermined  sets, 
and  whether  uniqueness  of    values  is  desired. 


23 


C.   EXISTING  PFOGRAHS 

Two  programs  were  reviewed  in  order  to  determine  which 
possesses  the  largest  number  of  desired  propertiss  and  still 
would  require  the  least  effort  to  ensure  system  compati- 
bility with  the  current  version  of  MDBS.  The  first  of  the 
twc     programs    was     originally      designed     in  [Ref.    3].  The 

second  was  a  latter  attempt  to  simplify  the  test  file  gener- 
ation  package. 

1-      The  Original   Test    File   Generation   Package 

In  this  program  the  test  data  is  generated  and 
stored  in  files.  Several  character istcs  of  the  file  are 
specified  ty  the  experimenter.  Each  file  is  given  a  name. 
The  data  in  the  records  is  specified  in  a  fixed  number  of 
attribute-value  pairs.  The  type  of  data  in  the  attributes 
is  integer,        string,     and     floating-point    numbers.  These 

values  are  generated  in  either  predetermined  files,  called 
sets,  created  by  the  experimenter,  or  are  randomly  generated 
by  separate  functions.  Only  a  uniform  distribution  of  the 
various  data  types  is  available.  This  program  contains  all 
of  the  desired  properties  stated  above,  except  the  ability 
to   guarantee   uniqueness  of  the   records  created. 

2.      The  Shortened   Test   File  Generation   Package 

This  program  was  written  in  order  to  reduce  the 
complexity  of  the  original  test  file  generation  package. 
Many  of  the  features  of  the  original  program  remain  intact. 
Two  important  differences  exist.  The  shortened  version  only 
allows  the  use  of  predetermined  sets  of  values  to  be  used, 
therefore     not     allowing    randomly     generated     values.  The 

second  difference  is  the  fact  that  the  files  generated  must 
be  of  length  of  less  than  or  equal  to  10,000  records.  An 
advantage   of      the   shortened   version      is   that  it     is   combined 
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with  the  shortened  database  load  program,  which  is  discussed 
in   the    following   section. 

D.  SELECTION    OF    THE    TEST    FILE    GENERATION    PACKAGE 

The  shortened  version  of  the  test  file  generation 
package  was  selected  initially  as  the  file  generation  tool. 
MDES  is  currently  undergoing  a  change  in  the  version  of  the 
compiler  used.  In  an  attempt  to  keep  the  conversion  of  MDBS 
simple,      the      shortened  version     was    chosen.  This    version 

allowed  a  rapid  conversion.  However,  cnly  user  defined  sets 
of  values  are  selected  for  the  attribute  values.  This  is 
considered  a  disadvantage.  Perhaps  the  overriding  consider- 
ation in  the  selection  of  the  shortened  version  was  the  fact 
that  its  associated  database  load  subsystem  was  much 
simplier.  The  discussion  of  this  subsystem  is  provided  in 
detail    in   the    following  section. 

E.  THE    UPGRADING    PROCESS 

The  upgrading  process  for  the  shortened  version  of  the 
test  file  generation  package  was  relatively  simple.  The  C 
compiler  originally  used  in  the  implementation  was  an  older 
version.  The  new  version  is  being  used  by  MDBS.  Several 
minor  compiler  differences  with  respect  to  acceptable  syntax 
were  rapidly  fixed. 

F.  FUTURE   IMPROVEHENTS 

Because  the  shortened  version  possesses  all  but  one  of 
the  desired  properies  discussed  in  chapter  II,  only  one 
future    change    is  anticipated. 

Two  approaches  which  provide  the  shortened  version  with 
the  capability  of  randomly  generating  values  exist.  The 
first   of   these    alternatives  includes    adding   the    functions   to 
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the  program  with  the  additional  user  interface  to  select 
these   as   options.  Tha    second  alternative  is      to   adap-   the 

original  test  fils  generation  package  to  be  compatible  with 
the  shortened  database  load.  The  task  would  be  simplified 
by   choosing  the   first   alternative. 

This  concludes  the  discussion  of  the  test  file  genera- 
tion tool.  In  the  following  chapter,  we  discuss  the  proper- 
ties of    the  selected   database    load   subsystem. 
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IV.    THE    DATABASE    LOAD   SUBSYSTEM 

In  this  chapter,  we  discuss  the  database  load  subsystsm 
development.  In  the  first  two  sections,  we  review  the 
purpose   and     desired   properties  of     the   subsystem.  In  the 

next  two  sections,  we  discuss  how  the  basic  program  was 
selected  from  existing  database  load  tools.  Finally,  in  the 
last  two  sections,  we  discuss  the  upgrading  of  the  selected 
program  and  future  enhancements  which  will  further  aid  the 
performance  evaluation  team. 

A.  THE    POBPOSE 

The  database  load  subsystem  is  a  software  tool  used  to 
designate  an  input  source  file  and  to  create  a  database  from 
that  source  file.  It  also  allows  several  related  files  to 
be   consolidated      into   one    database      if   desired.  The    first 

phase  in  the  database  load  subsystem  is  to  define  the  input 
files      and  the      database.  The     second   phase      consists     of 

constructing  various  directory  management  tables.  Lastly, 
the   records  are   distributed  across   the   backends. 

B.  DESIRED    PROPERTIES 

The  database  load  subsystem  must  be  designed  so  that  the 
performance  evaluation  may  utilize  various  cluster  formation 
variables  and  storage  variables  with  minimum  effort.  The 
performance  may  be  expected  to  depend  upon  whether  the 
number  of  descriptors  (attributes)  is  large  or  small.  The 
ease  of  specifying  the  descriptors  (attributes)  must  be 
guaranteed.  The     variation      of  cluster     size      may     affect 

performance.  The  cluster  size  is  a  function  of  the  number 
of   descriptors,    the   size    of  the  input    files,      and   the   values 
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used  in  the  attribute  fields.  These  three  parameters  should 
be     entered  independently.  The     data   placement      strategy, 

i.e.,  how  records  are  distributed  across  the  badcends,  also 
affects    performance.  The  ability  to  change      the   placement 

strategy  will  provide  a  means  of  confirming  simulation 
studies . 

C.      EXISTING    PROGRAMS 

Two    database      lead  subsystems     were    reviewed.  In   this 

section  the  merits  of  both  of  the  existing  programs  are 
discussed.  The  original  database  load  subsystem  is  covered 
first,  then  a  shortened  version  of  the  database  load 
subsystem    is   evaluated. 

1 •      The  Original    Cat a base    Load  Su  bsystem 

The  original  database  load  subsystem  was  first 
designed  at  the  beginning  of  the  implementation  stage  of 
MDBS.  The  process  is  viewed  as  four  logical  phases.  The 
first  phase  is  the  database  definition  phase,  in  which  the 
user  specifies  various  characteristics  of  existing  source 
files  and  the  characteristics  of  the  database  to  be  created. 
The  second  phase  is  the  record  preparation  phase,  in  which 
the  data  is  read  from  the  input  files  and  prepared  for 
loading.  The  third  phase  is  the  record  clustering  phase,  in 
which  the  prepared  records  are  sorted  into  clusters.  The 
last  phase  is  the  record  and  table  distribution  phase.  This 
phase  distributes  the  records  and  the  directory  management 
tables   to   the    backends. 

2-      The  Shortened   Database   Load   Subsystem 

As  stated  in  Chapter  II,  the  shortened  database  load 
subsystem  is  much  simpler  than  the  original  database  load 
subsystem.      This   implementation  can  be   viewed   as   two    phases. 
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The  first  chase  is  the  directory  table  construction  phase, 
in  which  specified  database  parameters  are  read  from 
existing  files  and  the  directory  tables  are  constructed. 
The  second  phase  is  the  record  distribution  phase.  In  this 
phase  the  records  are  distributed  to  the  backends  by  using 
insert      reguests.  Thus      this        subsystem      uses      currently 

existing  directory  management  functions  to  load  -he  database 
records. 

0.      THE    SBIECTION    OF    THE    DATABASE   LOAD   SUBSYSTEM 

Several  disadvantages  to  the  original  database  load 
program   exist.  Since  it   was      created   at   the      inception   of 

MDES  design,  it  possessed  many  system  incompatibilities  with 
the  current  version  of  MDBS.  Once  again  the  large  size  of 
the  program  posed  a  significant  maintenance  problem  with 
respect  to  the  conversion  of  the  system  to  the  new  compiler. 
For  these   reasons   this  program   was  not   selected. 

The  shortened  version  of  the  database  load  subsystem  was 
chosen  as  the  basis  for  the  database  load  tool.  This  was 
due  to  the  fact  that  it  used  existicg  directory  management 
code  and  that  it  was  much  simpler  to  understand  and  thus 
maintain. 

E.       THE    UPGRADING    PROCESS 

In  this  section,  we  now  discuss  the  upgrading  of  the 
shortened  version  of  the  database  load  subsystem.  A  discus- 
sion of  the  communication  among  processes  is  presented. 
Then  the  changes  to  the  database  load  subsystem  are 
discussed. 
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1-       Message   Passing 

In  order  to  load  the  current  version  of  MDBS,  it  is 
necessary  to  change  the  database  load  subsystem  so  that  it 
could  communicate  with  the  backend  process  of  directory 
management.  The  database  load  subsystem  is  impl3manted  as  a 
separate   process   in  the  controller.  A   brief    discussion   of 

message    passing  in   MDBS  is  presented    below. 

a.  Message  Passing  Within  a    Backend 

The   backends    are   supported  by   PDP-11/44s   running 
under   RSX-11M        operating        system.  The        inter-process- 

communication  facility  is  the  shared  access  to  physical 
memory.  Suppose   process     X      wants    to      send      a   message     to 

process  Y.  X  will  copy  the  message  into  the  shared  area. 
Then  X  tells  the  operating  system  to  send  the  address  of  the 
message  to  process  Y.  when  Y  is  ready  to  receive  a  message, 
it  gets  the  address  of  the  message  from  the  operating 
system1 s  queue  of  such  addresses.  Process  Y  then  copies  the 
message    into   its  own    memory  space. 

b.  Message  Passing  Within  the  Controller 

The   MDES     controller  is      a  VAX-11/780      using  the 
VMS     operating      system.  The     inter-process      communication 

facility  is  the  mailbox.  The  mailbox  is  a  software  input/ 
output   device.  If   process      X  wishes  to     send   process     Y    a 

message,  process  X  first  issues  a  send  command  to  process 
Y's  mailbox.  When  process  Y  issues  the  read  command  on  its 
mailbox  it  will  be  given  the  message  sent  by  process  X.  The 
mailbox    can  queue   several    messages. 
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c.      Message   Eassing   Between  Computers 

Communication  between  computers  in  MDBS  is 
achieved  by  using  a  tims-division-multiplexed  bus  called  the 
parallel  communication  link  (PCI)  .  Two  interface  processes 
to   the   PCL     are   used   in   each    computer.  The   first    process, 

called  put_PCLr  puts  the  message  to  be  sent  to  the  other 
computers  on  the  PCL.  The  seccnd  process,  called  get_PCL, 
receives  the  message  from  the  bus  and  then  passes  the 
message  to  the  appropriate  process.  PCLs  are  presently  used 
to  simulate  the  broadcast  bus  and  will  be  replaced  physi- 
cally  by    a  broadcasting  bus  later. 

2-      Directory.  Tables 

Several  directory  tables  exist  in  order  to  process 
requests.  In  this  section  the  logical  descriptions  of  such 
tables  are  discussed.  This  will  allow  some  insight  into 
what  kind  of  messages  must  be  sent  during  the  loading  of  the 
database. 

The  Attribute  Table  (AT)  contains  a  list  of  the 
directory  attributes  and  a  pointer  to  the  descriptors 
defined   on     these   attributes.  The    AT     is  located     at   each 

backend.  The      Descriptor-to-Cescriptor-Id      (DDIT)         Table 

contains  the  descriptors  and  their  corresponding  descriptor 
ids.  Each  section  of  the  DDIT  is  associated  with  a  direc- 
tory attribute  and  contains  the  descriptors  defined  on  that 
attribute.  The  DDIT  is  located  at  each  backend.  Since 
type-C  sub-descriptors  are  created  dynamically  as  new 
records  are  inserted,  the  type-C  attributes  must  be  recorded 
in  a  table  called  the  Type-C-Descriptor-Table  (TCDT) .  The 
TCDT  is  located  in  the  controller.  When  an  insert  request 
contains  a  record  with  a  type-C  attribute  and  the  value  of 
the  attribute  does  not  appear  in  a  type-C  descriptor,  a  new 
type-C   descriptor   will  be    created     by    the   Insert   Information 
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Generation  process.  This  process  will  then  record  the 
descriptor  in  the  TCDT.  Thus  all  directory  attributes  and 
their  corresponding  descriptors  are  sent  to  the  backend's 
Directory  Management  processes.  All  type-C  attributes  are 
also  sent  to  the  Insert  Information  Generation  process  in 
the  controller. 

3.      Specific  Dpgrades 

The  database  load  subsystem  program  was  changed  by 
allowing  it  to  communicate  with  the  backends  in  order  to 
load  the  database  to  the  backends.  In  order  -co  distribute 
the  directory  management  tables  to  all  backends,  the  data- 
base load  subsystem  must  be  given  its  own  mailbox  and  access 
to  the  directory  management  physical  areas  located  in  the 
backends.  All  of  the  functions  which  create  the  directory 
management  tables  were  moved  tc  the  backends  and  appropri- 
ately placed  in  the  directory  management  processes.  Data 
necessary  to  construct  these  tables  was  passed  to  the  back- 
ends  by  using  messages  containing  codes  which  indicate  the 
type     of   action      tc      be  taken.  Because      the    backends     can 

construct  the  tables  in  parallel,  this  did  not  significantly 
burden   the  database  lead    process.  In   order  to   support  the 

message  passing  ability,  send  and  receive  routines  specific 
to  the  database  lead  process  were  written.  Figure  4. 1 
illustrates  the  inter-process  communication  involved  with 
the  directory    table   ccnstructicn  phase. 

In  order  to  load  the  records  into  the  database, 
communication  between  the  request  preparation  process 
(located  in  the  controller)  and  the  database  load  subsystem 
was  established.  This  allowed  the  database  load  subsystem 
to  send  the  insert  requests  directly  to  request  preparation. 
Thus  the  database  load  subsystem  was  given  access  to  the 
request  preparation  mailbox.  It  was  also  necessary  to  send 
the  Insert  Information  Generation   process     all    of   the  type-C 
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Figure    4.1         COHHUNICATIONS:       DIRECTOHY    TABLE    CONSTRUCTION. 
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attributes  for  insertion  into  the  TCDT.  Figure  4.2  shows 
the  inter-process  communication  of  the  record  distribution 
phase. 

The  following   is   a  summary     of  the  types   of   messages 
which  were   added  to  the  database   load    subsystem: 


Message    type: 
Source: 

Destin  aticn: 
Explanation: 

Message    type: 

Source: 

Destination: 

Explanation: 

Message   type: 

Source: 

Destination: 

Explanation: 

Message  type: 

Source: 

Destination: 

Explanation: 

Message   type: 

Source: 

Destination: 

Explanation: 


(1)  Create    AT 
Database   Load     (EEL) 
Directory    Management 

This  message  creates  an   AT   for 
the   given    database    name. 

(2)  Add  Attribute  to   AT 
Database  Load     (DBL) 
Directory    Management 

This   message  adds  an  attribute 
to   the    AT    for    the  given    database. 

(3)  Add  Descriptor  to    DDIT 
Database  Load    (EBL) 
Directory    Management 

This   message  adds  a   descriptor 

to   the   DDIT   for    the   given    database. 

(4)  Add  the  end   cf  descriptor  flag 
Database  Load     (DEL) 

Directory    Management 

This   message  adds  the    flag   to  signal 

the   end  of    the    descriptor   list. 

(5)  Load  type-C 
Database  Load    (EBL) 

Insert   Information   Generation 

This   message  passes  the   type-C   attribute 

to   IIG   for    entry  into    the   TCDT. 
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Figure    4.2         CCHMONICATICNS:        RECORD    LOADING. 
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Message   type:       (6)    Insert    record 
Source:       Database  Load     (EEL) 
Destination:      Request  Preparation 
Explanation:      This   message  sends  the    record  to    be 
loaded   to    HP. 

Message    type:       (7)    Responses 

Source:       Directory    Management  and 

Insert   Information   Generation 
Destination:       Database  Load 

Explanation:       This   group    of    messages    informs    DBL    of 
action   that  is    actually  carried    out   as 
requested    by  the  above    messages    from 
DBL.      They    also   include   error  messages. 

Thus  for   each    of  the   messages       (1)      through    (5)  ,      a   type    (7) 
message      is  sent      tc      the      Database  lead      subsystem.  This 

concludes   the    upgrading  of  the    database   load  subsystem. 

P.      FUTURE   IMPROVEMENTS 

The  database  lead  subsystem  contains  all  of  the  desired 
properties  discussed  above  with  the  exception  of  the  ability 
to  change  the  data  placement  strategy.  Due  to  the  manner  in 
which  the  database  is  loaded,  this  would  require  a  change  in 
the     directory      management   process.  Further      research     is 

required   to     investigate   the      ramifications  of      changing  the 
directory     management     process.  This      feature     should     be 

delayed   until   the      system    conversion    to   the     new  compiler   is 
completed. 


36 


?.     THE    TEST  BEQDBST    GENERATIOS    PACKAGE 

In  this  chapter,  we  discuss  the  test  request  generation 
package  development.  In  the  first  two  sections,  we  review 
the  purpose  and  desired  properties  of  the  package.  In  the 
next  two  sections,  we  discuss  how  the  basic  program  was 
selected  from  existing  request  generation  tools.  Finally, 
in  the  last  two  sections,  we  discuss  the  upgrading  of  the 
selected  program  and  future  enhancements  which  will  further 
aid  the    performance  evaluation   team. 

A.  THE    PURPOSE 

The  purpose  of  the  test  request  generation  package  is  to 
provide  an  easy  means  of  creating  a  list  of  test  requests 
which  will  be  executed  in  order  to  test  MDBS.  The  package 
also  aids  the  evaluation  team  in  executing  the  list  of 
requests.  The  list  of  requests  are  saved  in  a  file  for 
future  use,  in  order  to  avcid  regenerating  the  list  of 
requests. 

B.  DESIRED   PROPERTIES 

Recall  that  the  test  request  generation  package  permits 
the  request  formation  variables  to  be  altered  by  the  evalua- 
tion team.  This  allows  the  following  to  be  varied:  the 
percentage  of  the  types  of  requests  (retrieve,  update, 
insert,  or  delete) ,  the  percentage  of  aggregate  operators 
(ave,  max,  min,  sum,  and  count)  in  retrieve  requests,  the 
complexity  of  the  request  query,  the  order  of  the  predicates 
appearing  in  the  reguest,  and  the  number  of  attributes  to  be 
projected   in   the   retrieve  request. 
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The  request  generation  package  must  also  possess  the 
ability  tc  allow  the  following  modifications:  vary  the 
length  of  the  transaction,  tag  requests  with  user  identifi- 
cation, retrieve  a  record  defined  over  the  null  descriptor, 
and  execute  a  retrieve  request  in  which  the  entire  clus-sr 
is  stored  at  one  backend  and  compare  the  performance  with  a 
reguest  which  retrieves  records  from  a  cluster  which  is 
stored   across    all    tackends. 

C.       EXISTIHG    PROGBABS 

Two  existing  programs  were  reviewed  in  ord  ar  to  select 
the  one  which  best  fits  the  desired  properties  and  is  compa- 
tibile  with  the  current  version  of  MDBS.  Both  programs 
implement  the  test  request  generation  package  in  the 
controller-  The  next  section  discusses  version  A  of  the 
test   reguest   generation  package.  Version   A   was   originally 

designed  at  the  commencement  of  the  implementation  of  MDBS. 
Version   B    was   a   later   version. 

1 .      Version   A 

Version  A  may  be  described  as  a  package  which  aids 
the  user  in  developing  a  list  of  requests.  The  user  is 
guided  through  the  construction  of  one  request  at  a  time. 
The  program  ensures  that  the  syntax  is  correct.  The  intent 
of  this  method  is  to  generate  a  small  number  of  requests 
which  are  thoughtfully  devised  in  order  to  test  specific 
features  cf  MDBS.  This  program  also  assumes  that  one  user 
will     execute    only     one  request     at      a  time.  The   user     is 

allowed  the  following  options  when  using  this  test  request 
generation  package:  generating  a  list  of  requests  for  later 
use,  retrieving  a  list  of  requests  to  be  executed  in  any 
order,  modifying  an  existing  list,  or  executing  a  list  of 
requests. 
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2.      Version   B 

Version  B  is  a  follow-on  package  to  Version  A.  It 
therefore  possesses  all  of  the  features  contained  in  Version 
A.  It  should  be  noted  that  Version  B  adds  the  ability  to 
use  the  concept  of  transactions.  Recall  that  a  transaction 
is  a  group  of  one  cr  more  requests.  Thus  the  requirement  of 
executing   only    one   request  at    a  time    is   removed. 

D.  THE    SELECTION   OF    THE    TEST    BEQUEST    GENERATION    PACKAGE 

Because  Version  B  contains  all  the  features  of  Version 
A,  Version  B  was  selected  as  the  test  request  generation 
package.  Because  this  version  arrived  at  the  current  imple- 
mentation site  cf  MDBS  rather  late  in  the  review  of  perform- 
ance evaluation  tools,  many  of  the  desired  features  must  be 
left  for  future  development.  This  does  not  detract  from  the 
usefulness  of  the  test  request  generation  package  as  it 
stands. 

E.  THE    UPGRADING    PROCESS 

The  majority  of  the  upgrading  accomplished  on  the  test 
request  generation  package  consisted  of  ensuring  that  the 
syntax  discrepancies  due  to  compiler  differences  were 
removed.  A  reorganization  of  the  file  location  of  MD3S 
resulted   in  many   changes   to  the  programs. 

F.  FUTURE   IMPROVEHENTS 

Several  enhancements  to  the  request  generation  package 
may     be    desirable.  Three  major     enhancements   include     the 

following:  program  generation  cf  requests,  simulation  of 
mutltiple  concurrent  users,  and  development  of  a  storage 
information  package  to  aid  in   request    selection. 
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1 •      2£2££§I   feneration  of    Bequests 

In  order  to  test  MDBS,  the  test  request  generation 
package  could  be  modified  to  contain  a  routine  which  gener- 
ates randcm  requests.  The  input  to  such  a  routine  would 
include  parameters  such  as  the  percentage  of  each  type  of 
request  to  be  generated  and  the  the  query  complexity.  Query 
complexity  involves  changing  tte  number  cf  predicates  in  the 
reguests.  This  ability  would  allow  the  evaluation  team  to 
easily  determine  which  type  of  request  is  most  efficient 
under   MDBS. 

2.      Simulation   of    Multiple   Concurrent   Users 

In  order  to  evaluate  the  effect  of  concurrency 
control,  MDBS  must  be  tested  while  several  users  are  using 
the  system.  By  providing  a  way  to  link  a  user  to  the 
requests  which  are  generated,  the  test  request  generation 
package      would    simulate     mutiple  users.  This    would      avoid 

processing  several  separate  files  of  requests.  This  would 
also  result  in  repeatable  experiments,  in  that  the  condi- 
tions resulting  from  executing  the  concurrent  user  requests 
could  be   duplicated. 

3-      The  Storage   Information  Package 

The  storage  information  package  would  allow  the 
experimenter  to  ask  specific  guestions  about  the  database 
storage  information  so  that  intelligent  queries  can  be 
derived.  The   questions      an    experimenter      might   ask      would 

include:  What  descriptors  are  associated  with  a  certain 
attribute?  What  descriptor  ids  define  a  certain  cluster 
number?    or  Where   is   cluster  one  stored? 

This  package  could  te  implemented  by  sending 
messages  to  the  backends.  Each  message  would  be  associated 
with  a    routine    which    walks     through  the   directory   management 
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tables  and  finds  the  appropriate  information  and  sends  it 
back  to  the  controller.  By  evaluating  the  responses  to  the 
messages,  more  meaningful  re  guests  can  be  constructed  in 
order  to    evaluate   specific   features  of   MDBS. 
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71.    ANALYSIS   Ql  PERFORMANCE   EVALOATION    TOOLS 

In  Chapter  I,  we  discussed  the  study  phase  of  creating 
the  tools.  In  Chapter  II,  we  discussed  the  design  phase. 
The  development  phase  was  outlined  in  Chapters  IIIr  IV,  and 
V.  In  this  chapter,  we  discuss  the  operational  phase.  This 
taxonomy  of  phases  is  outlined  in  detail  in  [Ref.  8].  More 
specifically,  in  this  chapter,  we  discuss  the  performance 
evaluation  tools  with  respect  to  several  software  engi- 
neering   principles. 

A.      BASIS    OF    ANALYSIS 

In  this  section,  wa  discuss  the  standards  by  which  the 
evaluation  tools  are  to  be  analyzed.  The  two  major  catego- 
ries of  the  analysis  are  the  ability  to  meet  the  objectives 
stated  in  the  design  phase  and  the  ability  to  mee-  software 
goals.  The  standards  are  described  in  detail  in  [Ref.  9] 
and  [Ref.    10]. 

The  ability  to  meet  objectives  means  that  the  tool  poss- 
esses the  capabilities  outlined  in  the  design  phase.  These 
capabilities   were   discussed   in   detail    in  Chapter   II. 

The  performance  evaluation  tools  will  be  evaluated  also 
by   their     ability   to   meet      five  software   goals.  The   first 

goal  is  that  of  mcdifiability .  Modifiability  includes  the 
properties  of  extensibility,  consistency,  maintainability, 
and  modularization.  The  second  goal  is  that  of  reliability. 
Reliability  includes  the  properties  of  possessing  no  blatent 
errors   and     of    possessing    error  recoverability.  The   third 

goal  is  simplicity.  This  includes  ease  of  use  and  singla- 
ness  of    purpose.  Efficiency   is   the    fourth     goal.        A   tool 

will  possess   this   goal  if    it   contains    no  gross   inefficiency. 
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The  last  software   goal   is  that  of   under standabiliry. 

Onderstandability  means  that  the  tool  utilizes  abstractions, 

modularity,   and  information  hiding,  and  is  supported  with 
reasonable  documentation. 

B.  ANALYSIS    OF    THE    FILE    GENERATION    PACKAGE 

The  objectives  of  the  file  generation  package  were 
discussed  in  Chapter  II.  The  objective  that  was  not  met  by 
this  tool  is  the  ability  to  indicate  whether  values  of  the 
attributes  are  taken  from  randcm  functions  or  predetermined 
sets  of  values.  The  random  functions  must  be  added  at  a 
future   date. 

The  file  generation  package  meets  all  goals  with  the 
exception  of  efficiency.  Modifiability  is  achieved  through 
the  extensive  use  of  modularization  with  respect  to  grouping 
like  operations  together.  Reliability  has  been  observed  in 
that  no  errors  have  existed  since  the  operational  phase. 
Simplicity  is  demonstrated  by  using  menu-driven  operations 
in  the  file  generation  package.  Lastly,  understandabilit y 
is  achieved  by  religious  use  of  abstraction  of  data  and 
operation.  The  gross  inefficiency  in  the  package  results 
from  the  use  of  a  large  array  which  is  used  to  store  the 
unique  records  which  are  generated.  When  a  large  number  of 
records  are  to  be  inserted  at  one  time,  the  time  to  compare 
the  new  record  against  all  previously  generated  records  is 
great.  This   concludes      the   evaluation      of     the   test      file 

generation  package. 

C.  ANALYSIS  OF  THE  DATABASE  LOAD  SUBSYSTEB 

The  objectives  of  the  database  load  subsystem  were 
discussed  in  Chapter  II.  The  objective  that  was  not  met  by 
this  tool  is  the  ability  to  vary  the  data  placement 
strategy.      This  ability  must    be  added    at   a    future   date. 
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The  database  load  subsystem  meets  all  goals  with  the 
exception  of  efficiency.  Modifiability  is  achiaved  through 
the  extensive  use  of  modularization  with  respect  to  grouping 
like  operations  together.  For  instance,  all  of  the  routines 
to  pass  messages  are  grouped  in  send  and  receive  modules 
which  are     kept   in     separate    files.  Reliability   has     been 

observed  in  that  no  errors  have  existed  since  the  opera- 
tional phase.  Simplicity  is  demonstrated  by  using  menu- 
driven  operations.  Lastly,  understan dability  is  achieved  by 
religious  use  of  abstraction  bcth  in  the  data  and  the  opera- 
tions. The  gross  inefficiency  in  the  package  results  from 
the  use  of  a  large  number  of  insert  requests-  which  are  sent 
one  at  a  time  to  the  backends.  This  inefficiency  could  be 
reduced  by  grcuping  several  insert  requests  into  a  trans- 
action and  then  sending  the  transaction  to  the  backends.  It 
is  also  possible  tc  save  all  type-C  descriptors  in  the  data- 
base load  subsystem  and  send  all  cf  them  to  Insert 
Information  Generation  at  the  end  of  the  directory  table 
loading.  This  concludes  the  evaluation  of  the  database  load 
subsystem. 

D.       ANALYSIS    OF    THE    BEQOBST    GENERATION    PACKAGE 

The  objectives  of  the  test  request  generation  package 
were  discussed  in  Chapter  II.  The  objectives  that  were  not 
met  by  this  tool  are  the  following  enhancements:  program 
generation  of  requests,  simulation  of  multiple  concurrent 
users,  and  development  of  a  storage  information  package  to 
aid  in  request  selection.  These  abilities  must  be  added  at 
a    future   date. 

The  test  request  generation  package  meets  all  goals  with 
the  exception  of  possessing  consistency.  Modifiability  is 
achieved  through  the  extensive  use  of  modularization  with 
respect   to  grouping  like   operations  together.      For   instance, 


44 


all  of  the  routines  which  are  involved  with  creating  a 
request  are  divided  into  modules  each  of  which  handles  a 
distinct     aspect     of      the      request.  This      goal      is      sear. 

throughout  MDBS,  Reliability  has  bsen  observed  in  that  no 
errors  have  existed  since  the  operational  phase.  Simplicity 
is  demonstrated  by  using  menu-driven  operations.  Lastly, 
understandability  is  achieved  fcy  religious  use  of  abstrac- 
tion both  in  the  data  and  the  operations.  Consistency  may 
be  achieved  by  altering  the  test  request  generation  to  use 
information  stored  in  the  files  generated  by  both  the  test 
file  generation  package  and  the  database  lead  subsytem. 
These  files  could  be  used  for  the  extraction  of  necessary 
information  instead  of  prompting  the  user  to  re-enter  data 
supplied  earlier.  It  is  the  weakest  link  in  establishing  a 
tight  performance   evaluation    environment.  This    is    further 

discussed    in   the   next   section.  This  concludes  the   evalua- 

tion of    the  database   load    subsystem. 

E.      FUTURE   DEVELGPHEHTS 

The  most  important  future  development  shou.ld  be  the 
integration  of  tt€  performance  evaluation  tools  into  a 
performance  evaluation  environment.  In  this  way,  the  prop- 
erty of  consistency  of  the  tools  will  be  attained.  That  isr 
the  output  of  one  tool  can  be  used  as  input  to  the  next  tool 
in  the  logical  sequence  of  the  performance  evaluation 
effort.  This  has  been  achieved  in  the  tesx  file  generation 
package-database   lead     subsytem  interface.  The    next     step 

would  be  to  develop  consistency  between  the  database  load 
subsystem-test    request  generation   package  interface. 

This  concludes  the  discussion  on  the  analysis  of  the 
performance  evaluation  tools. 
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711.    CONCLUSIONS 

In  this  thesis,  we  have  discussed  the  development  cf  the 
necessary  tools  for  the  performance  evaluation  of  a  multi- 
backend  database  system,  known  as  MDBS-  The  basic  motiva- 
tion of  the  mutlti-backend  database  system  (MDBS)  was  to 
develop  an  architecture  which  spreads  the  work  of  the  data- 
base system  among  multiple  backends.  It  was  a  major  aim  cf 
this  system  to  allcw  capacity  growth  by  the  use  of  addi- 
tional disk  drives  and  performance  improvement  by  -he  use  of 
additional   backends.  However,      to      verify  the      design  and 

implementation,  it  is  necessary  to  test  the  capability  of 
MDBS   in    capacity    grcwth  and   performance   gain. 

Three  tools  for  the  performance  and  capacity  tests  were 
investigated.  The      first     tccl   was      the      file     generation 

package  which  creates  test  files  for  any  artificial  data- 
base. The  second  tool  was  the  database  load  subsystem  which 
loads  the  artificial  database  into  MDBS.  The  third  tool  was 
the  request  generation  package.  This   package   created   test 

reguests   to  query   MDBS. 

The  following  methodology  was  used  to  crsate  an  effec- 
tive tool.  First,  the  properties  of  an  ideal  tool  were 
described.  Then  available  existing  programs  were  reviewed 
and  evaluated  to  determine  which  program  best  meets  the 
desired  features.  The  programs  were  upgraded  to  ensure  that 
they  were  compatible  with  the  current  implementation,  and 
met  the  desired  features.  Lastly,  the  tools  were  analyzed 
with  respect  to  meeting  the  desired  properties  and  satis- 
fying several    software  engineering  goals. 

The  main  goal  was  to  develop  the  necessary  tools  to 
generate  tests  in  measuring  the  extensibility  of  MDBS,  i.e., 
how     does        MDBS      perform      as        more      backends        are      added? 
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Performance  was  expected  to  improve  (maintain)  as  the  number 
(size)  of  the  fcackends  (database)  was  increased.  We  feel 
that  the  tools  developed  herein  will  allow  an  easy  and  effi- 
cient  means  of    measuring    the   extensibility    of   MDBS. 
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APPENDIX    A 
DBSIGH    SPECIFICATION  OF    THE    TEST   FILE    GENERATION    PACKAGE 

This  appendix  contains  the  design  cf  the  test  file 
generation  package  which  is  a  subset  of  the  shortened  data- 
base load  subsystem.  The  design  consists  of  C  language  code 
for  the  function  headings  and  xheir  corresponding  declara- 
tions.     The  body  of  the  functions   are    given   in    English   text. 


/*********************/ 
/*         TEST  FILE      */ 

/*  GENEEATION  */ 

/*  PACKAGE  */ 

/*  DESIGN  */ 

/*********************/ 


main_program  () 
begin 

generate()  ;    /*generate    the    records*/ 
end 


generate  () 

/*  This   routine  */ 

/*  -  generates   a  record    template  */ 

/*  -  aenerates/modif ies    sets  of    values  for  attributes  */ 

/*  -  generates   descriptors  */ 

/*  -  generates    records    using  the  sets  */ 

begin. 

while     (  TRUE    ) 
begin 

/♦Ask    the   user  for  type  of  operation   to   be   performed*/ 
/♦Take   appropriate  action*/ 

/*  generate   record  template  */ 

gen  tmpl  () ; 

/*  generate  descriptors  */ 

gen   desc  () ; 

/*   generate/modify  sets   */ 

gm_set()  ; 

/*   generate   the  records   */ 

gen   rec  ()  : 

/*  lead   the   records    */ 


end while; 
end 


db   load  (}  : 
/*c!o   nothing*/ 
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gen_tmpl() 

7*   This  routine  generates    a   record   template    ♦/ 
begin 

char      tfn (MFNLength  ♦    1);  /*  template-file    name   */ 

char       c,    dbid  (DBIDLNTH+  1)  ,    hold  (MAX   FIELDS+1)  ,    temtyp; 

int        i,   k,    no   attr; 

FILE      *fopen()7   *tmpl_fp; 

/*   Get    name    c£   template   file  */ 

/*  Open  template   file    */ 

/*   Get    database   ID    from  the   template    file*/ 

/*   Write  database   ID  to  template   file   */ 

/*  Get    number   of  attributes    */ 

/*   Write  number  of  attributes  to  template  file    */ 

/*  Get  attributes   and    value   tyoes    */" 

for    (each   attribute) 

begin 

/*    Enter   the   attribute    name*/ 

/*   Enter   the   value    type:    (s=string,    i=integer) */ 
end  /*   end   for   */ 

/*  Close  template   file    */ 
end     /*   end  gen   tmpl   */ 


gen_desc  () 

begin 

char      tfn (MFNLength  +    1);    /*  template-file   name  */ 
char      dfn  (MFNLength  +    1);    /*  descriptor-file    name    */ 
char   attr   name  (ANLength) , 

answer(5"),    desc_type#    val_type,    c,    hold(3)  ; 

int    i,    j,    nc_attr; 

FILE    *fopen  ()  ,    *tmpl_fp,    *desc_fp; 

/*   Get    the   template-file   na  ire  */ 

/*  Open  template   file    */ 

/*  Get   the    name   of  the    file   for    storing    descriptors   */ 

/*  Open   descriptor    file  */ 

/*   Read  thru   Databass    ID  to    get   */ 

/*  to   number   of  attributes  */ 

/*  Get   number  of  attributes    */ 

/*   For    each   attribute    get    its  descriptors    (if   applicable)*/ 
for    (each   attribute) 
begin 

/*   Read   attribute   */ 

/*   Get   attribute  name    */ 

/*    Get    value  type    for   the  attribute    */ 

/*    Ask    if   attribute 

is   to    be   a  directory   attribute*/ 

if    {  answer=  yes  ) 

begin 

/*    Write  attribute   name  to    descriptor   file    */ 

/*   Get   descriptor    type    for  attribute   */ 

/*    Write   descriptor  type  to   descriptor   file    */ 

if    (   desc  type   =    ,CI    |    desc  type   —    'c') 
gen   C  (val_ type, desc    f p)  ; 

else     "  ~ 

gen_notC  (val  type,desc  f  p)  ; 

/*    write   end  ofdata   symbol  to   descriptor   file   */ 

end 
end   /*    end    fcr   */ 
/*   Write  end_of_file  symbol   to   descriptor   file    */ 
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/*  Close  files    */ 
end/*gen_desc*/ 


gen_C(v al_type,  desc_f  p) 

char    val  type; 
FILE   *desc    ip; 
begin 

char    lcwerb  (AVLength)  ,    upperb  (AVLength)  ,   hold(3)  ; 
int   fault,k; 

/*   Get    upper   bounds  for   type   'C*    descriptors   */ 

while    (  TRUE  ) 

begin 

/*   Get   upper   bound    */ 
if    (  end   of   data) 
return ; 
else 
begin 

/*    Verify   upper  bound  entry   against   */ 
/*  attribute   value  type  */ 

/*  Write   NOBOOND    and    upper  bound   */ 

/*   to    descriptor    file  */ 

end 
end 
end  /*    end  gen   C      */ 


gen_notC ( val_type, desc_f p) 

char      val   type; 
FILE   *desc    rp; 
begin 

char    lewerb  (AVLength)  ,    upperb(AVLength)  ,   hold(3)  ; 
int  fault,    k; 

/*   Get    lower   and   upper    bounds  for   descriptor   */ 

while    (  TRUE   ) 

begin 

/*   Get   lower   bound    */ 
if    (    end   of   data) 

return; 
else 
begin 

/*   Verify    lower   bcund    entry  against   */ 
/*   attribute    value   type  */ 

/*    write   lower  bound  to  descriptor    file   */ 
end 
/*    Get   upper   bound    */ 

/*    Verify   upper    bound  entry   against   */ 
/*    attribute"  value   type  */ 

/*   Write    upoer   bound  to    descriptor  file   */ 
end   /*   end    while   */ 
end/*   end    gen    note   */ 


gm   set() 

"/(*  This  routine   generates/modifies    sets   of   values.    */ 
begin 

char    tfn (MFNIength   +    1)  ;   /*   template- file  name   */ 
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char   attr  name  (ANLength   ♦    1),   answer,    c,    val   type, 

hcldlAVLength   +1)  ; 
char    tmptyp; 
int    no_attr,    kr    i; 

FILE    *fopen(),    *tmpl_fp; 

/*   get   the   template-file   naiie  */ 

/*  Open  template    file    */ 

/*  Get   number  of  attributes    */ 

for    (    each    attribute  ) 

begin 

/*    Get    attribute  name   */ 
/*   Get    value   type    */ 

/*   Choose    the   action   to   be   taken   on   attribute 
n)      -     generate  a   new  set    for    it 
m)      -     modify   an  existing    set    for   it 
s)       -     do  nothing   with    it  */ 

switch (    answer   ) 
begin 

case    ,nl: 

/*  generat*  new  set   */ 

§en   set(    val   type   )  ; 
reak ; 
case    •m1 : 

mod_set(val  type) ; 
break; 
case    •s1 : 

break; 
end       /*   end  switch   */ 
end        /*  end   for  */ 
/*  Close  template   file    */ 
end       /*    end   gm   set  */ 


gen_set  (val_type) 

/*  This  routine   generates   a   set   */ 
/♦of    values    for   an   attribute.   */ 

char      val   type; 
begin 

struct    definition 
begin 

char    elem(SetSize)  (AVLength  ♦    1)  ; 

/*  array   for   holding    set  elements  */ 

int  no    elem: 

/*  numEer  of   elements   in  set  */ 

end   set; 

char    f ilnam (MFN Length    ♦    1), 

entry  (AVLength  ♦    1),    answer(5)  ; 
int    k,    fault,   limit; 

FILE    *fopen(),    *tmpl_fp; 

/*   Get    name    of   set   file  */ 

/*  Open  set    file   */ 

/*   Accept    elements    for    the    set   */ 

while    (  set    is   not   full) 

begin 

/*  Enter   a  value    for    the  set*/ 

/*  Verify   set  entry   againsx    attribute    type    */ 

/*  Check   for   set    element   duplication   */ 

end 
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if    (    set  is    full) 

/*  Tell   user*/ 
/*  Write  set    elements   to   set  file    */ 
/*   Write  end   of   file  symbol   to   set    file   */ 
/*  Close  set~file   */ 
/*  Ask   if    user   wants  to   modify   it    */ 
if    (   answers   yes   ) 
mod   set (val   type) ; 
end  /*   en  a"  gen    se^   */ 


mod_set  (val_type) 

/*   This  routine   modifies  a    set   */ 
/*  of   values    for   an  attribute.    */ 

char      val_type; 
begin 

char  ofn  (MFNIength    +    1) ,    /*  old-file  name   */ 

nfn  (MFNIength   ♦    1)  ,    /*   new-file   name    */ 

filnam  (MFNIength  +    1); 


c,  answer  (5) ,    entr y(AVIength 
i,    kr    fault,j; 


char   c,  answer  (5) ,    entr y(AVIength    +    1),    index(5) 
int 


struct 

begin 
int        no    elem;   /*  number   of   elements   in   the    set   */ 
char     rel   flag  (SetSize)  ;    /*   element   removed    flag    */ 
char     elem(Sef Size)  (AVIength   ♦    1);    /*   elements   */ 

end   set; 

FILE    *f  open  ()r    *set_fp; 

/*   Get   the    r.ame   cf   the    set    tc  be   modified   */ 

/*  Open  file   */ 

/*   Read  given   file   into  array  for    manipulation   */ 

while    (  TRUE  ) 

begin 

/*    Ask   what    do   you    want    tc  perform   next?*/ 

print    the    set    elements   and    their    indices 
add  some   elements    to   the   set 
remove  some  elements    from   the   set 
(n)      -     nothinq;   done 
if    (  answer   ■    "p"   ) 
begin 

/*  Print   elements  of    file   */ 
end/*  end    (   answer    =    *p*    )    */ 
else  if    (   answer  =    •a'    ) 
begin 

/*   Add  some   elements   */ 
/*   Check    for  set  element  duplication    */ 
/*   Verify  entry    against    */ 
/*   attribute  value   type   */ 
/*   Add   element    to  array     if    correct*/ 
end  /*   end    (   answer   =    'a1    )     */ 

else   if    (   answer  ■    • r*    ) 
begin 

/*  Remove  some  elements  */ 
/*  Mark  set   elements    for   removal   ♦/ 
/*  Re-crder   array  to    reflect    deletions   */ 
end     /*   end    (  answer   =    ' r1   )    */ 
else 

/*  Nothing;    done    */ 
creak;        /*   exit    while  */ 
end      /*  end    while    (  TRUE  )     */ 
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/*   Ask   if    user   wants  to  store  the    modified  set    back 

into  the  original  file   */ 
/*  Write  array   back  into   file  designated*/ 
/*   Write  end   of   file  symbol   to   set    file    */ 
/*  Close  set~"file   */ 
end/*  end   mod    set   */ 


gen  rec  (1  .  , 

7*  This  routine   generates    records    using   ssts.    */ 
begin 

char   c 


char   hold(AVIength   +   1)  ; 
char    attr_nane  (AVLength  +    1) 


char      dbid (DBIDLNTH  ♦    1) . 

gr   records  (MAX   RECORDS)  (MRLength   ♦    1); 
char      tfnfMFNLength  T    1)  ,    /*  template-fila   name   */ 

rfn (MFNLength  +    1),    /*  record-file   name   */ 
vfn  (MFNLength   +    1)  ;    /*   temporary   file   name   */ 


struct 
begin 

int   no  elemfMAX   FIELDS); 

char   elems  (MAX  TIELDS)  (Setsize)  (AVLength   +    1)  ; 
end    values; 

FILE   *fopen(),    *tmpl_fp,   *rec_fp,    *stor_fp; 

int    no   attr*    k,    i,    j,    count-  gr_r.o    rec,    max, 
rec_cnt,    prcd,    index,    old;  — 

/*   Get   the   template-file   na ne  */ 

/*  Open  template   file    */ 

/*  Get    file    for   record    storage   */ 

/*   Open  record   file  */ 

/*  Read  database   ID  */ 

/*    Write  database   ID  to  storage   file   */ 

/*  Read  number   of   attributes  in  a    record    */ 

/*  Read  elements  of  files   corresponding    to   */ 

/*  each  attribute   into    an    array  */ 

for    (    each    attribute) 

begin 

/*   Read  the   attribute  name  */ 

/*   Get   the   file   name  for   the   given   attribute   */ 

/*   Open    file   */ 

/*    Read   elements  of    set    into  array   */ 

/*  Close  file  */ 
end  /*  end  for  */ 
/*  Close  template    file    */ 

/*   Calculate   total   possible    number   of    unique   records    */ 
/*  Get   the    number   of  records  to   be    generated   */ 
/*   Determine    feasibility  of   requested   number   */ 
/*   Generate    records  by    choosing    (at   random)    */ 
/*   a    member    from   each    of  the  given    sets  */ 

for    (    each   record) 
begin 

for    (for   each   attribute) 
begin 

/*  Get    a   value  randomly  from    the   set*/ 
end 

/*    Give    some   feedback   tc  user    cf   generation   effort*/ 
/*   Check   generated    record  for    possible   duplication   */ 
end 

/*   Write  generated   records    tc  file    */ 
/*  Write  end   of    file  symbol   to   file   */ 
/*  Let   user   Tcnow   when    completed*/ 
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/*  Close  file   */ 
end/*  end   gen_rec   */ 


int  gr_isdigit  (c) 

/*   This  routine   determines   whether    a   given   */ 
/*  character    is  a   digit      */ 

char  c ; 
begin 

if    (   c   is  a    digit   ) 

return  (TRUE)  ; 
else 

return (FALSE) ; 
end 


gs_rand  (num) 

/*   This  routine    cenerates   a    random    number  */ 

int    num; 
begin 

static  long   seed; 

static  int   temp: 

seed   =  seed   *   2U298    ♦   temF  ♦    time(O); 

seed   =  seedmod199017  ; 

seed   =    (69069   *   seed    +    1)  : 

temp   =    (seed   >>    8)    &    32767; 

if    (    num   ==   0   ) 

return (temp) ; 
else 

return  (temp   mod  num)  ; 

end 
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APPENDIX    B 
DESIGH   SPECIFICATIOH    OP  THE  DATABASE    LOAD    SUBSYSTEM 

This  appendix  contains  the  design  of  the  shortened  data- 
base load  subsystem.  The  design  consists  of  C  language  code 
for  the  function  headings  and  their  corresponding  declara- 
tions.     The  body  of  the  functions   are    given  in    English   text. 

/****************  */ 

/*  L  V 

/*  Database  Load  */ 

/*  Design  */ 

/*  V 

struct   rtemp_def inition  template; 

db   load  () 

/*   This    routine   loads   the    directory  tables   and   the   database    */ 

/*   records.  */ 

begin 

/*    Initialize   counters*/ 

/*   load   the  directory  tables   */ 

dbl    dir   tblsj)  ; 

/*   Ioad'the  database  records   */ 

dbl    records  ()  ; 
end 


dbl_dir    tbls() 

?*  Th"is  routine   loads    the   directory   tables.    */ 
begin 

char  dbid(DBIDLNTH    +    1)  , 

attrname  (ANLength    ♦    1) , 

tfn fMFNLength    ♦    1),    /*   template-file    name    */ 

dfn  (MFNLength    ♦   1)  ,    /*   descriptor-file    name   */ 

valtype, 

str  (f  r 

attrstr  (DII  Attria    +1)  , 

desctype;     " 

int   at_id_no,   desc_id_no; 

struct      desc_def  inition     descriptor; 

int        i,  k ,    c; 

FILE   *fopen  () ,    *fptr; 

/*  Initialize   the   database    mailbox*/ 

/*  Get   the   name   cf  the    file   containing   */ 

/*   the  template   information   */ 

/*   Read  the    database  id   */ 
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/*  Head  number  of   entries    in  the  template,    i.e.,*/ 
/*  number   of   attributes   in   a  record  */ 

/*  Read  the    attribute    names   and  the  value  types   */ 
/*  and   place  the    data    in  the  template    record  */ 

for    (    each   attribute  to  be    put   in    template) 
begin 

/*  Read   an   attribute    */ 
/*  Read   the   corresponding   value    type  */ 
end 

/*   Create   attribute  table   for  the    database   in   backends   */ 
DBL   S$Create  (dbid)  ; 

/*  Get   the   name   cf  the    file   containing   the   descriptors   */ 
/*  Read  the    directory   attributes  and  their   */ 
/*   corresponding   descriptors  */ 

/*   Initialize  the   attribute   counter  */ 
while     (  not    the   end  of    data   ) 
begin 

/*  Read   an   attribute    */ 

/*  Read   corresponding   descriptor  typ»    A,B,   or   C  */ 
/*  Add   the  attribute    name  to   the  a-xribute   table  */ 
cBL    S$Atm   insert  (dbid, attrna  me,  &desctyoe)  ; 
if  7desctype   =    ■  c1    J    desctyoe   ■■    '  C')" 
/*   Send  the  attribute   to   IIG  */ 
DBL   SSsend   typeCfdbid .attrname ,at   id   no); 
/*  Using   t"Ee   template,   find   the   value    */""     "" 
/*  type   for   the   attribute   */ 
/*  Read  the   corresponding   descriptors*/ 
/*  for   the  attribute    */ 
/*  Inititialize   the   descriptor   id    */ 
while    (   More   descriptors   ) 
begin 

/*   Get  lower    bound   */ 

/*   Get  upper   bcund   */ 

/*   Add  the  descriptor    to   DDIT   */ 

DBL   S$Desc_add  (dbid.a ttrname.&desctype, 

Edescnptor.Svaltype,  at_id   no,desc  id  no); 
/*   Increment    the  descriptor  io"   count   */  ™ 
end   /*   end   while    */ 
if    {    desctype  !=    C  ) 
begin 

/*    Add   the  catchall  descriptor   to   DDIT  */ 
DBL   SSCstchall  (dbid, attrname. 

Edesctype,  at   id   no,desc  id  no); 
end  /*   end   it  */     " 
/*  Increment   the   attribute  count   */ 
end   /*  end    while    */ 
/*   Close    descriptor    file    */ 
end/*  end    dbl    dir  tbls  */ 


dbl^records  () 
begin 

char  dbid  (DBIDLNTH    ♦   1)  , 

rfn (MFNLength    +1),    /*    record-file    name    */ 
req (REQIength)  , 
record]80J ; 
struct     rtemp_definition     *tnjpl   ptr, 

*aet  fmpl   ptr()  ; 
mt   1,    c; 

FILE   *fopen(),    *fptr; 

/*  Get   the   name   cf  the    file    */ 

/*   containing   the   records   to  be    loaded   */ 

/*   Read  the    database  id   */ 

/*  Get   the    record  template    for  the    database    */ 
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while    (  more   records  exist    ) 

begin 

/*  While   there  are   more  records   */ 
/*  Read  the   next    one  */ 

/*  Construct   a  request  to  insert   record    */ 
dbl   construct  ins  (  tmpl  ptr,    record,    req    ); 
/*  Send   the   request    tc  "Request-Preparation    */ 
EBL   S$TrafUnit(dbid,    req)  ; 
end 
end     /*   end   dfcl_r€cords   */ 


dbl_construct_ins  (tmpl_ptr ,    record,   req) 

struct  rtemp   definition     *tmpl_ptr; 

char  req  (J7   record  ()  ; 
begin 

int    i,  j,    k,    p,    entry_.no; 

/*  Load  the    initial  part  of   request   */ 
while    (  not    the    end  of    the    record    ) 
begin 

/*  Load    the  attribute    came   */ 
/*  Load    the   attribute    value   */ 
end 

/*   Load   the    end  of   request    */ 
end 
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APPENDIX    C 
DBSIGN    SPECIFICATION    OP   THE   TEST   REQUEST    GENERATION    PACKAGE 

i) 
The    program      specification   for   the  test     request    genera- 
tion and   execution   package  is    shewn  in   this  appendix.        This 
design    is   the   result   of  the  work  of  Dr.    Kerr,    who    headed  the 
design   cf   the    original  test   request   generation    package. 

The  Top   Level   cf  Test  Request   Generation  Package 

This  program  can  be  used  tc  test  and  demonstrate  MDBS. 
The  execution  cf  this  program  is  called  a  session.  Each 
session  can  be  divided  into  any  number  of  subsessions. 
During   a   subsession  the  user    can  do  one    of   the    following: 

(A)  Execute  a  list  of  requests  that  was  previously 
stored   in  a   file. 

(B)  Prompt  the  user  for  a  list  of  requests  to  be 
stored   in  a   file   for   later    use. 

(C)  Retrieve  a  list  cf  requests  that  were  previ- 
ously stored  in  a  file  and  then  allow  the  user  to 
select  requests  frcm  that  list  for  execution. 
This  selection  can  be  done  in  any  order.  The  user 
will  also  be  able  to  enter  a  new  request  to  be 
executed. 

(D)  Modify  an  existing  list  of  requests  that  was 
previously   stored  in   a  file. 

In  this  version,  requests  are  allowed  to  be  grouped  as 
transactions.  A  reguest  is  sent  to  MDBS.  The  program  waits 
for  a  response  before  sending  the  next  request  or  will 
continue    to  execute   without  response    if   the   user   so    desires. 

Output  may  be  directed  to  the  user's  terminal  or  to  a 
file  or   tc  both. 

Program   Specificat  ions 
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/*  */ 

/*  Test  Bequest   */ 

/*       Generation  */ 

/*  Package   Design      */ 
/*  */ 

task         MDES    T^st* 

scalar        more-sufcsessions ;   /*    flag:   TRUE  -   continue, 

FALSE   -    stop    */ 

Print   initial   message  to   user; 
more- sutsess ions    :=   TRUE; 

while        more-subsessions        do 
perform        SOBSESSION; 
Prompt   for  continue    message; 
Read  continue   message; 

if        user   dees  not   want  to   continue 
then 

more-subsessions    :=   FALSE; 
end  if 
end  while      ; 

end  task      ; 

procedure        SOBSESSION; 

/*   During  a   subsession    the   user  is   able  */ 

/*                       to   generate    a  group  of    requests.     (NEW      LIST)  */ 

/*                       to   modify  an  old   list  of   requests.    (M0T3IFY).  */ 

/*                       to   selecx  requests,    one    at  a    time    from   a   lisu  */ 

/*                                 of   requests.     (SELECT)  */ 

/*                       to   run   a  group   of  requests.    (OLD LIST)  */ 

scalar        current-reguest-f  ile;    /*  The    name   of   the    file   */ 

/*   Initial   value  should    be  NOLL.    This   name   must    be  */ 

/*      retained   from  one  subsession   to  the   next.  */ 

scalar        type-of-subsession;    /*  Possible   values   are  NEW     LIST, 
MODIFY,     SELECT    and    OLD LIST    */ 

Prompt   for  next   type-of-subsession; 
Read    next  type-of-subsession; 

case       type-of-subsession        value 

NEW LIST:   /*   Enter    a  new  request-list   */ 

perform        NEW      LIST     SOB(    current-request-f ile)  ; 
MODIFY:    /*   Modify  an~"old   list   */ 

perform        nODIFY_    SOB(   current-request-file  ): 
SELECT:    /*   Select  requests,    one    at  a    time,    from  an   */ 
/*  existing    request-list   */ 
perform        SELECT      SOBf   current-request-file   )  ; 
OLD      LIST:    /*   Execute  an   existing   request-list    */ 

perform        OLD      LIST SOB(    current-reguest-f ile)  ; 

otherwise      :    Prin^errcr  message; 
end  case      ; 

end  procedure      ; 

procedure        NEW LIST SOB(        output      :    current-request -file   ); 

scalar       current-request-file;    /*   name  of  the    file   */ 

/*  Asks    user    for   requests  -    ere  at   a   time.  */ 

/*  Saves  list   of   requests  in    a  file    with   file-name   given   by   */ 
/*  user.  */ 

scalar        request-list-file-name; 

/*    of  file  tc   use  to  store  the    requests   */ 
record        request; 
scalar        next-step; 
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/*    I(nsert),    R(etrieve),    U(pdate),    D(elste)    or    F(inish)     */ 

Prompt   for  reguest-}.ist-file-name; 
Read   reguest-Iist-f lie-name; 
Open   filef   request-list-file-name  )    output; 

perform      ENTER_    AND_SAVE      REQUESTS  (    reguest-list-f ile-na me    ); 
Close    file(    request -list -fTls-name    ); 
current-request-file   :-    request-list-file-name; 
end  procedure      ; 

procedure    MODIFY SOB  (        input /output      :    current-request-file    ); 

scalar       current-request-file;    /*   The   name    of   the   file   */ 

/*  Retrieve    an   eld    reguest-list  and    then  allow   the    user   to      */ 

/*  modify  it.      Requests    are    examined  one  at   a   time    allowing   */ 

/*  changes   to    te    made  to  each  request   in  turn.      A   change           */ 

/*  can   Be  */ 

/*               add   new   reguest    before  this    one.  */ 

/*               modify  this   request.  */ 

/*              remove   this   request.  */ 

/*               make    no   changes    to   this   request.  */ 
/*  Note    that    we   must  have  a    way  to    append  new    requests  at         */ 

/*  the    end   of   the   input    request   list.  */ 

/*                                                          .  */ 

/*  The    input    file    (   called   input -re  quest-file   )     may   be  */ 

/*  either  the   current- re  quest-file    or  a   different   existiag  */ 

/*  request   file.  */ 

/*  */ 

/*  The    output  file    (  called    new-request-file    )    may    be                 */ 

/*  either  the  nsxt   version   of  the  mput-request-file   or   a         */ 

/*  new   file.  */ 

scalar        input-request-file;    /*  The  list   of   requests 

to  be  modifies.    */ 
scalar        new-request-file;    /*    The   new    list   of   requests.    */ 
scalar        next-versicn;   /*    flag:TROE-set   new-raquest-f ile  ta    */ 

/♦next    version   of   input-reguest-file,    FALSE-get    new   name*/ 
record        reguest; 

scalar        more-reguests-in-input-reguest-file:/*continue   flag*/ 
scalar        mcre-reguests-to-enter;  /*  continuation   flag   */ 
scalar        change-type;    /*   ADD,    MODIFY,    REMOVE,    or   NOCHANGE  */ 

scalar        next-step; 

/*    I(nsert)  ,   R  (etrieve)  ,    U(pdate),    D  (elate)    or    F(inish)*/ 

/*  Determine    input-reguest-file   to    be   modified-    */ 

perform        DETERMINE  _INPUT FILEf    current-request-file, 

input-reguest-file   )  ; 
open    file(   input-request-file  )    input; 

/♦Determine  if    user   wants   the    name    of    the  new-request-file*/ 
/*   to  be    the   next   version    of   the  input-request- file*/ 
/*   or   a    new  name.*/ 

Prompt    user    to    determine  next-versicn; 
Read   next-version; 
if        next-version 
then 

Set   new-request- file    tc  next   version    of 
in  put-re  quest- file; 
else 

Prompt   for   new-request-f iie    name; 
Read    name  of  new-request-file; 
end  if       ; 

open   file(   new-request-file    )    output; 

Read    first   request   from    input-reguest-file; 
more- reguests-in-input-reguest-f lie    :=   TRUE; 
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while        more-reguests-in-icput-re  guest-file        do 
Prompt   user   for   change-type   for    this   request; 
Read  change-type: 

case        change-type        value 

ADD:    /*    enter  and  save  the    next   request   */ 

perform        GET_    NEW REQUEST  (  request    ); 

Write  request  inTc  new- request-f ila ; 
MODIFY: 


REMOVE: 

Read  next  request   from    input-request-file; 
NO_CHANGE: 

Write  current  request  into   nev-request-file; 
Read  next  request  from    input-request-file; 
otherwise     :    Print   system    error   message; 
end  case      ; 

end  while      ; 

/*  Note  that  at  this  Doint  all  the  eld  requests  have  beea  */ 
/*  processed.  However  it  is  possible  that  the  user  wants  */ 
/*  to    append    more   requests.  */ 

Prompt    user    that    input    file    has   been   processed,    but   that 
more   requests   may  still    be  apoended; 

perform        ENTER  _AND SAVE      REQOE  STS  (ne  w-raquest-f  ile)  ; 

close    file(   input-request-f ile  )  ; 
close    file(    new-request- file   ); 
current-request-fils  :=   new-request-file; 
end  procedure      ; 

procedure        SELECT     SDB(input/cutput      :    current-request -file   )  ; 
scalar        currenT-request-f ile;    /*    The   name    of   the   file   */ 

/*  Retrieve    an   old   list    of   requests,  */ 

/*  Allow  user   to   select    from   this  list.  */ 

/*   Also   allow   user   to  enter    new   request.  */ 

scalar      input-request-file:  /*   file  containing  requests*/ 

array        reguests(   MAX NUMBER_   CF_   REQUESTS   ); 

/*   frcm   lnput-reguesf-f  ile    */ 

scalar        number-of-reguests:   /*  The   actual  number   in  */ 
/*    input-reguest-file  must  be   less   than  */ 

/*    MAX NUMBER CP       REQUESTS  */ 

scalar        reguest-numBer;    /*  of   the   request  chosen   */ 
record        new-request*    /*    Provided  by    user.    */ 
record        response;   /*  to    the   request    being  executed.    */ 

scalar        mcre-tc-execute;    /*    flag  to   control  loop    */ 

scalar        next-operation; 

/*    Values    can   be  REQUEST      NUMBER,    DISPLAY,*/ 
/*    NEW REQUEST    or    STOP    —  */ 

/*  Determine   the   new  input-reguest-file   to  use   for   */ 
/*  this   subsession.    */ 

perform        DETERMINE  _INPUT      FILEf    current-request-file, 

input-reguest-file   )  ; 
open(    input-request-file   ) ; 
Read   and  store   input-request-file  into  requests   checking   that 

number-of-requests  is    less   than  MAX      NUMBER      OF     REQUESTS; 
close  (   input-reguest-file  )  ; 

perform        DISPLAY  (  requests  ); 

/♦Determine   whether   response    is  to   go   to   CRT,    file  or    both*/ 
perform        OUTMSFORMAT; 
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more-to-execute    :=   TRUE; 

while        more-to-execute        do 

Prompt    user    for   next-operation    /*should   be    either*/ 
/*    request-number,    a  request-to-display   or   a  */ 

/*   new-request  */ 

Read  next-operation; 

case        next-operation        value 
REQUEST       NUMBER: 

Checl?  that    request-number   is  less   than 
num  ber-o  f-requests; 
perform        EXEC0TE(   re  quests  (request-number)  , 
re  s  p  on  s  e   )  * 
/*  Output  the  response    to   CRT,   file   or   CRT_Sfile, 
as    appropriate.    */ 
perform        CUTM$BESPONSE(   response    )  ; 

DISPLAY:        perform        DISPLAY(   requests   ); 
NEW       BEQUEST: 

perform        GET      NEW_   REQUEST(  new-request  ); 
perform        EXE€"UTE(   new-request,    response  )  ; 
/*   Output   the    response   to   CRT,   file    or   CRT   Sfile, 

as  appropriate.    */ 
perform        OUTMSBESPONSE  (    response    ); 

STOP:    more-to-execute   :=   FALSE; 
otherwise      :    print    error    messaqe; 
end  cas€      ; 

end  while      ; 

perform        OUTMSFINISH; 
current-request-file  :=    input-request-file; 

end  procedure      ; 

procedure        OLD      LIST SUB (  current-request-file   ); 

scalar        cuff ent-request-f ile;    /*    The   name    of   the   file   */ 

/*  Retrieve   and   execute   an    old  list   of   requests.    */ 

scalar        input-request-file  /*   The   file   containing  requests*/ 

record        request; 

record        response;    /*   to   a   request   that   has  been  executed.    */ 

/*  Determine    the   new  current-request-file  to    use   for   this*/ 
/*  subsession.    */ 

perform        DETERMINE  _INPUT FILET    current-request-file, 

input-request-tile  )  ; 
Open (    input-request-file  )     input; 
Read   first   request   from    input-request-file; 

/*   Determine    whether  response  is   to   go   to  CRT,    file   or   both.    */ 
perform        OUTM$FOEMAT; 
while        more-requests        do 

perform        EXECUTE (   request,    response  ); 
/*    Output   the   response    to  CRT,    file  or  CRT   &file,    as   */ 
/*    appropriate.    */ 

perform        CUTMSRESPONSE  (  response  ); 
Read  next   request  from   input-request-file; 
end  while      ; 

perform        OUTM$FINIS0: 
close  (    mput-request-f  lie  )  ; 
current-request-file  :=    input-request-file; 

end  procedure      ; 
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procedure        ENTER      AND SAVE BEQUESTS 

(         input      7~reguest-list-file- name  ) ; 
scalar        request-list -file -nam**; 

/*   of   file  to   use  to   store  the    requests   */ 
record        request; 
scalar        next-step; 
/*  I(nsert),    R  (etrieve)  ,    U(pdate),    D  (elete)    or   F(inish)    */ 

next-step   :=    I; 

while        next- step   °=   F        do 
Prompt   for   next-step; 

case        next-step        value 

I:   /*  enter    and   save  the    next    insert   request   */ 
perform        INSERT      SDE(    request  )  ; 

Write  request    into  request-list-file-name    ; 
R:    /*enter  and  save  next    retrieve    request   */ 

perform        RETRIEVE SOB(   request    ); 

Write  request   into  request-list- file-name    ; 

0:    /*  enter    and   save  the    next    update   request   */ 

perform         DELETE_    SUB(   request    ): 

Write  request   into  f equest-Iist-f ile-name    ; 

D:   /*  enter    and   save  the    next    delete   request   */ 

perform        DELETE SOB (   reguest   ): 

Write  request    into  r equest-Iist-f ile-name    ; 
F:    /*    Finish    entering    requests   */ 

otherwise      :   Print  error  messaqe; 
end  case       ; 

end  while      ; 

end  procedure      ; 

procedure        DETERMINE INPUT      FILE(        input      : 

current-reguest-f ile , 

output       :    input-request-file    ) ; 

scalar        current-request- file; 

scalar        input-request -file; 

/*  Determine   the   input    file    tc  be  used.      It   may  be    either*/ 
/*  the   current-request-file    or  a   different  existing  */ 

/*  request    file.  */ 

scalar        modify- curr ent-file -flag; 

/*   TRUE    -  select   new    input   file  */ 

if        current- request-file    is   NULL 
then 

Prompt    for    name   of    input-reguest-f ile ; 
Bead  name  of   input-request-file: 
else        /*   Determine   if    user  wants   to  use   the    */ 

/*   current-request-file   or    a    different    old   file.    */ 
Prompt   user   to    deter  nine   modif y-current- file- flag ; 
Read    modify-curr ent-f ile-flag; 
if        mcdify-current-file-flag 
then 

Prompt    for    name  of    input-reguest-f ile; 
Read  name  of   input- request-file ; 
else 

input- request-file    :=   current-request -file; 
end  if      ; 

end    if      ; 
end  procedure      ; 

procedure        GET      NEW      REQUEST  (        output      :    request   ); 

recSfd     "request;    /*  to  be   obtained   from    user   */ 
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end 


/*   Prompts   user  for   information   necessary  to   enter  a    */ 
/*    new    request.      Returns  the  request.  */ 


scalar        request-type; 

/*    I(nsert),    R(etrieve),    U(pdate)    or 


D (elate)    */ 


Prompt   fcr   next    request-type; 
Read    request-type; 


case 
I: 
D: 
D: 
R: 


end 


request-type  value 
perform  INSERT  SOB 
aPDATE""SOB 
DELETE  "SUB 
RETRIEVE  _Sl 
Print  error 


perform 
p  e  r  f  o  r  m 
perform 
otherwise 
case 


procedure 


reques 

reques 

reques 

B (    requ 

message 


procedure        DISPLAY  (       input      :   requests   \; 

/*   Display  the    requests   and   their   numbers    at   the   */ 
/*   terminal.  */ 


end 


array 
procedure 


requests (    MAX       NUMBER       OF      REQUESTS    ); 
/*    to  be~ displayed."*/ 


procedure        EXECUTE  (        input       :    request, 

output      :    response    ) ; 
/*   Ask   MDBS    to   execute   this    request.    Return   the   response.     */ 


end 


record    request;  /*  to    be  executed  */ 

record   response;    /*  to   the   execution  of   the   request    */ 

procedure      ; 
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